We have some ideas in common for sure (i.e. storing with upsin/camlistore and grabbing the embedded previews for display). Though, my needs go much further (i.e. being able to process my raw images with Go). I stick every RAW image from my D800 in Google Cloud Storage with the plan to eventually do something like that. We should discuss this separately at some point.
The biggest issue with the multipage TIFF support being added to the current tiff package is that the intent was to only support the base requirements (the first IFD and only the base and some extended tags). It might not be a lot of code or trouble to support processing additional IFDs, but I want to caution against supporting much more than that without rethinking the API and scope of the package. The TIFF data structures are pretty simple, but what you do with the data and how you process the data in them can get complicated when you start adding support for more tags and devices. It is something I really want to see though. On Mon, Sep 25, 2017 at 11:37 AM, Andrew O'Neill <foolus...@gmail.com> wrote: > I'm currently travelling with a Nikon D750. From what I can tell the raw > images use a single IFD with 2 SubIFDs the main one being the embedded jpeg > for the thumbnail and the second being the raw image data. If you have > something to parse the raw image data that would be awesome. I've been > testing some different storage solutions (upspin, camlistore) and wanted to > build something that would watch for newly added RAW images and create jpeg > thumbnails, and various sizes for sharing via blog, twitter, whatever. > > On Monday, September 25, 2017 at 3:40:25 PM UTC+2, Jonathan Pittman wrote: >> >> Wether a multi-page TIFF uses multiple IFDs or uses one IFD with multiple >> SubIFDs is implementation dependent. Though, I think most probably just >> use multiple IFDs. The basic structure of an IFD and a SubIFD is >> essentially the same. The main difference is where you find their offsets >> and the offset for the next IFD. If you want to just grab all of the >> regular IFDs, that is pretty easy to do. The "next offset" to the next IFD >> is at the end of the IFD's structure. You just go to that next offset and >> then process the IFD just like you did the first one. Grabbing SubIFDs >> requires you to look for the SubIFD tag (330 or 0x014a) inside an IFD and >> process the value field into a list of offsets values as a []uint32. There >> could be one or more offsets. Keep in mind that with SubIFDs, while the >> tag ID, its purpose, and format are documented and not intended to be >> changed, some manufacturers will ignore this and reuse the field for >> something else. Sony did this on at least one camera model that I know >> of. Most uses I have seen adhere to the original purpose though. >> >> If you want to see some (unfortunately) undocumented and very incomplete >> code for processing the basic data structures of a tiff (i.e. getting IFDs >> and SubIFDs, but not going as far as processing the actual image data), I >> posted some code here github.com/google/tiff. The godoc page >> <https://godoc.org/github.com/google/tiff> is more useful I think. I >> started on this code a while back, but have not had time to revisit it in >> depth in a while. >> >> Andrew, which camera makes and models do you shoot with? I have a Nikon >> D200 and a D800. I started working on model specific data structures for >> multiple camera models at https://godoc.org/github.com/google/cameraraw. >> I actually have code to generate those go files based on a TIFF/DNG/RAW >> file. It is just not checked in anywhere. >> >> On Monday, September 25, 2017 at 7:10:40 AM UTC-4, Tad Vizbaras wrote: >>> >>> If you implement decoder I can provide sample multi-page TIFF files to >>> see if it is working. >>> >>> On Sunday, September 24, 2017 at 2:48:50 PM UTC-4, Andrew O'Neill wrote: >>>> >>>> A while ago I reading Adobe's doc's on SubIFD's since that is needed >>>> for decoding Nikon's RAW files. Is this a similar thing or is it just >>>> reading all the IFD's? I plan to implement a SubIFD decoder for tiff, >>>> unless someone else has done it. >>>> >>>> On Sun, Sep 24, 2017 at 8:21 PM Tad Vizbaras <eta...@gmail.com> wrote: >>>> >>>>> Sad. >>>>> >>>>> Any chance to add multi page support to this? I am in desperate need >>>>> for multi-page TIFF support. >>>>> >>>>> >>>>> On Sunday, September 24, 2017 at 9:20:31 AM UTC-4, Guy Allard wrote: >>>>>> >>>>>> This package does not appear to support multi-page TIFs. Decoder >>>>>> initialization only reads the 1st IFD. >>>>>> >>>>>> On Friday, September 22, 2017 at 1:49:47 PM UTC-4, Tad Vizbaras wrote: >>>>>>> >>>>>>> No problem reading single page TIFF images using: >>>>>>> "golang.org/x/image/tiff". >>>>>>> >>>>>>> It works great. >>>>>>> >>>>>>> >>>>>>> Question: how to read multi-page scanned TIFFs? How to access pages 2, >>>>>>> 3, etc.? >>>>>>> >>>>>>> >>>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "golang-nuts" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to golang-nuts...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/golang-nuts/-FH2y0iGHLI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
