Who wants to use Go to process your camera's raw files?

[Jonathan Pittman]

Well me too!  I am looking to see what level of interest there is in the Go community to see this happen.  I am also looking for people who are interested in working on this.

Figuring out how to handle this problem for one specific camera's raw files is not too difficult.  Figuring out how to do this to handle the majority of cases requires a bit more work.

To be clear, I am wanting a pure Go solution that is better thought out, better laid out, and better to use than the existing C/C++ options.

[Sam Whited]

On Tue, Jul 26, 2016 at 9:35 PM, Jonathan Pittman
<jonathan.m...@gmail.com> wrote:
> Figuring out how to handle this problem for one specific camera's raw files
> is not too difficult. Figuring out how to do this to handle the majority of
> cases requires a bit more work.

I know libraw has its issues (and lots of them), and I completely
understand wanting a native Go way to get raw data, but I highly
recommend that you don't. There's absolutely no standard for raw image
file formats (most of them are slightly-off-standard variants of TIFF
with various silly transformations applied to the metadata for no
reason) between camera vendors, or even between different models made
by specific cameras. You'll be wasting a lot of time and effort trying
to duplicate the work that libraw has already done for you (and done
well). Instead, consider contributing to libraw if you see cameras
that it doesn't support.

That being said, if you wanted to talk about processing raw bayer data
without using cgo, I'd say go for it! Use libraw to actually extract
the data, then do the image manipulation itself in Go instead of using
libraws dcraw emulation layer.

I'm one of the authors of RawKit
(https://rawkit.readthedocs.io/en/latest/), a Python library for photo
manipulation that ships with libraw ctype bindings, and this is the
approach we will eventually take (although we'll most likely be doing
the photo manipulation in Rust, the raw extraction with libraw, and
just writing Python bindings for both).

—Sam

[Peter Herth]

Hi Jonathan,

I think its an excellent idea, and would be possibly interested to contribute. I am not really familiar with libraw, but there would be quite some good reasons to have a pure Go version, as long as not too much work is duplicated:

- a pure Go might have cleaner code and be easier to hack

- as there just was a remote exploit based on image files, the additional security of Go would be a strong argument

- I don't know how much libraw uses multithreading, but a goroutine based code would be nice to utilize modern cpus.

- in general it is always good to add quality native libraries to the Go universe. Often people get introduced to a language by the presence of good libraries.

Peter

--
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.

[simran]

+1, i'd be keen to contribute to a native go library too... 

--
sent from my phone

[Jonathan Pittman]

Sam, I do not think that I can use LibRAW (or LibTIFF) on appengine.  And I aim to write and run some apps on appengine that will let me do some things with my RAW images (not just the thumbnail or the jpeg previews).

Extracting the data (and metadata) is the easy part.  I have written things in Go that can do that all day long (makernotes are usually always more involved of course).  Knowing what to do with the data after you extracted it is the piece that makes this more complex.  Most of the libraries (LibTIFF and LibRAW) out there tend to enumerate all of the things they want to support and how to handle them.  I want something much more flexible than that.

I am fairly familiar with the different variations of metadata and embedded structures from different camera manufacturers and how they like to abuse some formats.  Not just that, but as you say, most of them are really just TIFFs under the hood.  For the files that are not TIFF, this becomes much easier as long as you have the file format specification.

My initial aim is to solve the TIFF problem in a flexible way that all TIFF based use cases can benefit from, not just camera raw files.  I have seen people write their own TIFF implementations just to handle a single case (e.g. EXIF parsing, image preview extraction, bio-medical imaging, GIS imaging).  None of these provide a common foundation that all cases can use.  This is not an easy problem to solve, but I think it can be made more elegant than existing implementations.  I see TIFF as a multi-layered issue.

The first and simplest piece is the basic file structure.  The structure of the tiff header and top level IFDs are pretty straightforward (even in BigTIFF) and easy to parse.  This should be its own package.  Why?  Because EXIF/GPS will use it and others may also.  A lot of people do not realize it, but almost every camera phone (and consumer and professional camera) that produces a JPEG, also embeds a TIFF file inside the APP1 marker segment of that JPEG.  But instead of containing what people think of as a traditional TIFF image, it contains EXIF metadata and sometimes GPS metadata.  The basic structure is the same, the data being represented might be different.

The second piece is the types, tag IDs, tag spaces, tag sets, and tag values.  This is really an adaption layer on top of the file structure that leads to metadata interpretation and/or image data with values to process and apply to the image content found within.  This could be a separate package, but could also live with the package containing the file structures.  The field types are especially beneficial to interpreting fields instead of just entries in an IFD (they are different).

The third piece is the image handling and processing.  This can definitely be its own separate package.  The idea is that in the second piece, you interpreted all of the tags to mean something, but the image layer knows what to do with that data.  The basic package should only handle baseline and extended tiff tags and values.

And this is where I envision the specifics begin to break out.  The idea I have would involve being able to register new types and new tags with the base tiff package.  The baseline and extended tags (and their values) would be baked right into the library, but there will be room for growth and functions to register new tag IDs, values, and types.  Add to this the registration of handlers to take over when certain tags and values are seen.  Some examples:

1. Tag 50706 is DNGVersion.  If seen, pass a TIFF object over to a DNG image handling library for processing.
   
2. Tag 271 & 272 are Make & Model respectively.  If the Make is "NIKON CORPORATION" and the Model is "NIKON D800", then pass the TIFF object over to a handler registered to process files from a Nikon D800.

The idea here being that, if we do not support some new tag value or camera in the base package, you can write your own package to implement the pieces you need and register it with the base package while all of the other plumbing just works.  There will be a lot of overlap in functionality in those libraries at first.  But much of that can be centralized where it makes sense and be made accessible for future common use (e.g. compression values referencing compression methods).

I know it is a lot of work.  I have been thinking about this for a few years and even started prototyping some of it, but I really would like to see it happen.  I have hit a few roadblocks in design and implementation, but more importantly I simply do not have the time to tackle this myself anymore.  I also agree with Peter Herth that good quality native libraries are good for the existing community as well as for enticing newcomers to the language.

Thoughts from anyone on this?

[Seb Binet]

On Thu, Jul 28, 2016 at 5:44 AM, Jonathan Pittman <jonathan.m...@gmail.com> wrote:

Sam, I do not think that I can use LibRAW (or LibTIFF) on appengine.  And I aim to write and run some apps on appengine that will let me do some things with my RAW images (not just the thumbnail or the jpeg previews).

Extracting the data (and metadata) is the easy part.  I have written things in Go that can do that all day long (makernotes are usually always more involved of course).  Knowing what to do with the data after you extracted it is the piece that makes this more complex.  Most of the libraries (LibTIFF and LibRAW) out there tend to enumerate all of the things they want to support and how to handle them.  I want something much more flexible than that.

I am fairly familiar with the different variations of metadata and embedded structures from different camera manufacturers and how they like to abuse some formats.  Not just that, but as you say, most of them are really just TIFFs under the hood.  For the files that are not TIFF, this becomes much easier as long as you have the file format specification.

My initial aim is to solve the TIFF problem in a flexible way that all TIFF based use cases can benefit from, not just camera raw files.  I have seen people write their own TIFF implementations just to handle a single case (e.g. EXIF parsing, image preview extraction, bio-medical imaging, GIS imaging).  None of these provide a common foundation that all cases can use.  This is not an easy problem to solve, but I think it can be made more elegant than existing implementations.  I see TIFF as a multi-layered issue.

The first and simplest piece is the basic file structure.  The structure of the tiff header and top level IFDs are pretty straightforward (even in BigTIFF) and easy to parse.  This should be its own package.  Why?  Because EXIF/GPS will use it and others may also.  A lot of people do not realize it, but almost every camera phone (and consumer and professional camera) that produces a JPEG, also embeds a TIFF file inside the APP1 marker segment of that JPEG.  But instead of containing what people think of as a traditional TIFF image, it contains EXIF metadata and sometimes GPS metadata.  The basic structure is the same, the data being represented might be different.

The second piece is the types, tag IDs, tag spaces, tag sets, and tag values.  This is really an adaption layer on top of the file structure that leads to metadata interpretation and/or image data with values to process and apply to the image content found within.  This could be a separate package, but could also live with the package containing the file structures.  The field types are especially beneficial to interpreting fields instead of just entries in an IFD (they are different).

The third piece is the image handling and processing.  This can definitely be its own separate package.  The idea is that in the second piece, you interpreted all of the tags to mean something, but the image layer knows what to do with that data.  The basic package should only handle baseline and extended tiff tags and values.

And this is where I envision the specifics begin to break out.  The idea I have would involve being able to register new types and new tags with the base tiff package.  The baseline and extended tags (and their values) would be baked right into the library, but there will be room for growth and functions to register new tag IDs, values, and types.  Add to this the registration of handlers to take over when certain tags and values are seen.  Some examples:

1. Tag 50706 is DNGVersion.  If seen, pass a TIFF object over to a DNG image handling library for processing.
   
2. Tag 271 & 272 are Make & Model respectively.  If the Make is "NIKON CORPORATION" and the Model is "NIKON D800", then pass the TIFF object over to a handler registered to process files from a Nikon D800.

The idea here being that, if we do not support some new tag value or camera in the base package, you can write your own package to implement the pieces you need and register it with the base package while all of the other plumbing just works.  There will be a lot of overlap in functionality in those libraries at first.  But much of that can be centralized where it makes sense and be made accessible for future common use (e.g. compression values referencing compression methods).

I know it is a lot of work.  I have been thinking about this for a few years and even started prototyping some of it, but I really would like to see it happen.  I have hit a few roadblocks in design and implementation, but more importantly I simply do not have the time to tackle this myself anymore.  I also agree with Peter Herth that good quality native libraries are good for the existing community as well as for enticing newcomers to the language.

Thoughts from anyone on this?

I guess the next logical step is to start an organization on github, put some design notes and some code... and let people come :)

I know (or strongly suspect) this could be useful for astronomy hobbyists...

-s

[Guy Allard]

If you put something up on github, please let us know here.

[Robert Carlsen]

FWIW https://github.com/rwcarlsen/goexif (my neglected of late project) has some rudimentary and (somewhat) generic tiff parsing capability.  I'm not volunteering for anything - just thought it might be a useful reference for someone working on this sort of thing.

[jonathan...@gmail.com]

I would be interested in seeing this happen.

[Jonathan Pittman]

For some reason I did not get the last 3 updates until this one.  Weird.

So, I have looked over a number of packages that parse tiff files.  While, at the most basic level, they all have to do the same sort of things, each one also approaches the situation a little differently.  And more so, the end result tends to be for custom use cases.

I already have code up on github.  You will have to excuse my lack of good documentation and tests.  I was originally planning to just do a proof of concept for how this might work.  So, it needs some cleaning up.  I am also in the process of making some changes to it including the LICENSE.  No pull requests at this time please, but do have a look if you like.

I would like to see some real discussion about the approach before writing any more code.  I am not sure the best way to go about this discussion.  Does email work for everyone?  Should we use the go proposal method?  A shared google doc?  I would like this to eventually make its way to the golang.org/x/image repo.  I would like to see a collection of use cases that we can include when trying to solve this in an appropriate and general way.

[Cristian Măgherușan-Stanciu]

What if the libraw C codebase would be converted to Go using the same approach done when the golang compiler was translated to go?

[Jonathan Pittman]

A lot of people would love to see that happen, not for the sake of this situation, but for the sake of being able to translate C to Go in moderately large projects and general uses.  If you or someone else has a way to do that, then that would be very interesting to see.

Having said that, I think there is also a point here about the use of C-isms in a Go code base.  We are writing Go code, not C/C++ code.  There are likely things we can do with Go to make the library and APIs much nicer to use.  And I would like to see that instead of just translating libtiff or libraw.

On Thu, Aug 11, 2016 at 2:10 AM, Cristian Măgherușan-Stanciu <cristi.m...@gmail.com> wrote:

What if the libraw C codebase would be converted to Go using the same approach done when the golang compiler was translated to go?

--
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/60WthPS_TXg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscribe@googlegroups.com.

[Cristian Măgherușan-Stanciu]

I'm not familiar with the process nor with the tools that were used, but I guess there are people on this list who may be able to point you to those. I suppose if it was feasible for something as large and complex as a compiler, it should be much easier for comparatively smaller pieces of software like this kind of library. As for the C-isms, those can be refactored over time, making the code closer to idiomatic go.

The problem with converting such libraries to Go is mostly philosophical, related to the fact that there may be other software written in C/C++ and other languages using them out there, and many other languages can use C/C++ libraries through bindings but those may not exist for software written in Go. Making a library in Go might render tools written in other languages unable to use the Go version of the library, and it would eventually cause fragmentation and duplication of effort, which may not be desirable.

[Michael Jones]

Transpilation is not the way to go. Many C/C++ “metaphors” do not translate naturally so an application-level runtime library would be forced to deal with void* pointer/data manipulations, data unions, and other concepts more properly redone in the new language mindset. Redo seems best, accessing through cgo seems most practical, and the magic generation of ugly Go code seems least appealing.

 

Michael

 

P.S. I love both Go and photography (https://michaeljonesphotography.smugmug.com/), so the marriage of the two is always welcome.

--

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.

[Guy Allard]

For how to go about discussion: 

would a google group work?

Or possibly an organization on github?

Personally I could go with almost anything.

[Jonathan Pittman]

Maybe not an organization on github, not for just this.  I could see a google group, but I am not sure about that either.  We have golang-nuts already.

--

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/60WthPS_TXg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscribe@googlegroups.com.

[Peter Herth]

As one would want a clean Go library, I think this library should be implemented from scratch in Go - there is also a better chance to get a really good performing library, if it is designed in Go and not in C. One obvious thing is, to do all heavy computations in parallel via goroutines.

Finally, there is the licensing question - only when implementing from scratch, one is free to choose the license for the library. I would strongly argue in favor of using one of the BSD/MIT licenses, as these are the most commonly used licenses in the Go community and impose the least friction for interaction and usage.

Peter

--

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+unsubscribe@googlegroups.com.

[Evan Digby]

This is something I would be interested in working on/supporting. I have 14 month old twins so I have to limit my expectations for coding outside of work these days, but this type of project I'd be keen on as an amateur photographer/astrophotographer. I've often looked at contributing to existing OSS projects but find myself not enjoying C/C++ these days. Outside of work I need to code in what I enjoy :)

I'd be interested to see how Go performs in this space

Are you thinking a lib/cmd line util/api for use by others, or are you thinking full end-to-end tools with GUI? There are many steps in the chain from raw to finished product. Are you just thinking digital darkroom, or full blown editing? Where on the toolchain do you see this?

[Evan Digby]

Sorry, I didn't see your longer high-level overview post--I see the vision a bit more clearly now.

Have you used slack? It might be a good place to start discussion to hammer out some details before moving onto a google doc. I find shared google docs can be challenging without at least a foundation discussed up-front. 

Slack is free for this type of thing (https://gophers.slack.com/pricing). I know lots of people dislike it, but I find it quite useful for the sort of semi-formal discussion that seeds this type of project.

[Paul]

DCRAW pretty much does it all. Its straight C under GPLv2.  Dave Coffin reverse engineered a lot of stuff to get it to work. It would be a sizable duplication of effort to try to do all that again.  From what I gather even Adobe uses his stuff. It should be possible to reference his code base in C and rewrite it in Go,  I think. The question would be, what is the point? Its probably already fast as hell and it likely will not need a garbage collector. Whatever... 

[Peter Herth]

Dcraw seems to be only partially gpl - otherwise Adobe couldn't use it in its products. Having a parallel version of the raw converter could yield conversion times far faster then the original C. And it would be a neat Go library to have. 

Peter

--

[Klaus Post]

On Wednesday, 27 July 2016 04:36:31 UTC+2, Jonathan Pittman wrote:

Well me too!  I am looking to see what level of interest there is in the Go community to see this happen.  I am also looking for people who are interested in working on this.

(a bit late to the party)

I am the author of RawSpeed - https://github.com/klauspost/rawspeed - which is a RAW decoding library which currently supports >700 cameras. It decodes to CFA-level images, so processing is still required to make the image "viewable". It is used by "Darktable" as well as other open source projects. It has even been stolen (oh sorry - converted) by raw.pics.io for their browser based decoding.

In my own humble opinion the code quality is way above dcraw, and I and other people have spent a lot of time trying to work out what goes on under the hood. Metadata is in a readable separate XML file (yes, this was designed in 2008), and not scattered around a single CPP file. Furthermore it is LGPL v2, but with a rewrite to Go, it should probably be MIT or similar. 

The code should translate rather well to Go - there is no big problems with it. Finding a decoder, parsing file structure and decoding images are nicely separated. Only the "RawImageData" seems to have accumulated a lot of fields and methods over time. It is rather sparsely commented, but I think the code should be pretty clear for a Gopher.

There are some design decision made that makes it faster by design. It decodes from raw memory and not a stream which makes it much faster to "jump around" without having to seek in the input stream. It decodes to unpadded memory which makes it use less memory and generally faster. Decoders have been heavily optimized for speed, while always maintaining full quality.

I have considered converting it to Go almost since I started programming, but since the demand for it is probably pretty small and I don't have a few months to spend on it, I have not done so. I am willing to help out the extent my knowledge

/Klaus

[Klaus Post]

On Saturday, 13 August 2016 17:18:16 UTC+2, Paul wrote:

From what I gather even Adobe uses [dcraw].

I am pretty sure it is the other way around. Observing for years, it seems like dc is reverse engineering the Adobe DNG Converter. His color conversion matrices are definitely from that, and his support mostly follows a DNG converter release.

It should be possible to reference his code base in C and rewrite it in Go,  I think.

Have you read dcraw.c? I have spent hours "reverse-engineering" what his code does. It is a spagetti of jumps, hoops, global variables, secret values, weird dependencies, etc.

/Klaus

[Klaus Post]

On Saturday, 13 August 2016 17:22:29 UTC+2, Peter Herth wrote:

Dcraw seems to be only partially gpl

Just to be clear, it is a "do what you want" license with only the Foveon decoding being GPL v2 (the RESTRICTED part).

I have reimplemented the Foveon code here: https://github.com/klauspost/rawspeed/tree/develop/RawSpeed (See X3fParser/X3fDecoder) - the processing of Foveon is not part of the library though.

/Klaus

[Klaus Post]

On Saturday, 13 August 2016 17:22:29 UTC+2, Peter Herth wrote:

Having a parallel version of the raw converter could yield conversion times far faster then the original C. And it would be a neat Go library to have. 

For the biggest part, I would not expect you to be able to beat C code, for that there is too much pointer arithmetic going on. The forced bounds checks will probably eat around 20% of your speed. The Go 1.7 SSA compiler will however help bringing us to the 20% overhead.

In terms of multithreading - only a few formats can be decoded multithreaded. Most formats are some sort of LJPEG, where every pixel depends on previous data - forcing you to do single threaded decoding. DNG being the only "big" exception. 

For uncompressed formats, you are just moving bits, so multithreading gives you little advantage. RawSpeed has multithreaded decoding of images where it is possible.

/Klaus

[Paul]

On Saturday, August 13, 2016 at 8:06:44 PM UTC+2, Klaus Post wrote:

On Saturday, 13 August 2016 17:18:16 UTC+2, Paul wrote:

From what I gather even Adobe uses [dcraw].

I am pretty sure it is the other way around. Observing for years, it seems like dc is reverse engineering the Adobe DNG Converter. His color conversion matrices are definitely from that, and his support mostly follows a DNG converter release.

I could'nt remember where I read it, but it actually says so in the adobe forum Quote:
"ACR contains some stuff from dcraw, and dcraw contains some stuff from ACR."

It should be possible to reference his code base in C and rewrite it in Go,  I think.

Have you read dcraw.c? I have spent hours "reverse-engineering" what his code does. It is a spagetti of jumps, hoops, global variables, secret values, weird dependencies, etc.

/Klaus

Well apart from the 'code quality', his code does seem to be of interest to quite a few software developers in the graphics business,  including yourself as you write.  Adobe would have their own special reasons for using some of his stuff. 

I was not even aware of Rawspeed. I do use Darktable, however there is quite some discussion going on as to the quality of the images that opensource raw converters produce. Adobe seems to still be king of that hill. Or poprietary Converters such as Capture Nx2 which very unfortunately has been discontinued.

  

[Klaus Post]

On Saturday, 13 August 2016 23:21:31 UTC+2, Paul wrote:

I was not even aware of Rawspeed. I do use Darktable, however there is quite some discussion going on as to the quality of the images that opensource raw converters produce. Adobe seems to still be king of that hill. [...]

Image quality is for the most part a matter of what is done to the image after the decoding stage, primarily demosaic (image detail) and colour profiles (image look/color/contrast). 

For demosaic, dcraw has some good options, and I have been wanting to try a neural network supported demosaic for years. 

For color quality, darktable has done a lot of work, or you could use Adobe DCP (DNG Color Profile) profiles, which we have implemented for RawStudio - see https://github.com/rawstudio/rawstudio/tree/master/plugins/dcp - this gives you access to all colour profiles from Adobe as well as your own. dcraw uses a very simplified version of Adobes profiles. Here is a blog post I wrote about 6 years ago: https://rawstudio.org/blog/?p=236

/Klaus

[Jonathan Pittman]

Klaus, thank you for your input and pointing us to RawSpeed.  I glanced through it and noticed one of the approaches you take is to create decoders based on the "format" and use camera Make/Model tags to decide which decoder to use.  I am glad to say this is also the approach I was taking and mentioned in an earlier post.  I was wondering if there was a better way, but I think this works the best.

To everyone, I really want to see this live in the golang.org/x/image repo.  Do we need to create a formal proposal for it to live there?  Should we do the initial development in another repo and then move it to the x/image repo later?

For a place to have the discussions, I was going to say that I like the idea of Slack, but the free pricing has limits on searching archives (i.e. reasons for historical decisions may get lost).  Then I realized that the gopher slack is on the standard tier instead of the free one.  So, maybe this can actually work.  For Slack, can we just add a channel to gophers.slack.com?  I do not spend much time on there now.  So, I do not know the rules for that kind of thing.

Does Slack work for everyone?  Or would most people prefer a new mailing list?

--
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/60WthPS_TXg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscribe@googlegroups.com.

[Nigel Tao]

On Mon, Aug 29, 2016 at 12:27 PM, Jonathan Pittman
<jonathan.m...@gmail.com> wrote:
> To everyone, I really want to see this live in the golang.org/x/image repo.
> Do we need to create a formal proposal for it to live there? Should we do
> the initial development in another repo and then move it to the x/image repo
> later?

I'm open to this eventually living under golang.org/x/image/..., but I
think you'll move faster if you start the initial development in a
separate repo.

[Jonathan Pittman]

Does the license need to be the same as the standard Go License if it starts in another repo and then moves over?

[Nigel Tao]

On Thu, Sep 1, 2016 at 12:46 PM, Jonathan Pittman
<jonathan.m...@gmail.com> wrote:
> Does the license need to be the same as the standard Go License if it starts
> in another repo and then moves over?

IANAL, but that seems best.

[Will Norris]

If you start in a separate repo, make sure you are checking CLAs all along the way (I can help you set that up if needed).  Otherwise, any move into /x/image just becomes that much more difficult.

And yes, I would definitely start with the standard Go license.

--

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+unsubscribe@googlegroups.com.

[pierb...@gmail.com]

Any updates on this?

I'm looking at processing RAW images in a server with Go.

On Tuesday, July 26, 2016 at 9:36:31 PM UTC-5, Jonathan Pittman wrote:

Well me too!  I am looking to see what level of interest there is in the Go community to see this happen.  I am also looking for people who are interested in working on this.

[Jonathan Pittman]

Unfortunately not from my end.  I have had a lot going on at work and home.  Time to work on this has escaped me.

I did manage to move my initial prototyping work over to github.com/google/tiff and update the LICENSE to match the Go license.  So, this is where we can make changes or blow it all away and start fresh.

I will be at GopherCon this year (and GothamGo) if anyone wants to meet up and discuss or start hacking on this.

--
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/60WthPS_TXg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscribe@googlegroups.com.